In the field of this invention it is known that, in computer software, whenever objects are created under user control there is a chance that they will not be destroyed again. In languages such as C and C++ both the creation and deletion of objects are directly under user control and the result was that many large projects found cases where memory would be consumed but not returned. Often these ‘memory leakage’ problems were too difficult to locate and correct and the result would be that the programs would fail periodically. Over the years there have been many attempts to remove these problems from the user domain and ‘garbage collected’ languages such as Smalltalk and Java have become popular. In these languages the user no longer controls the deletion of objects, rather they are automatically reclaimed when no longer referenced by the program. Hence the traditional ‘memory leakage’ might be considered a thing of the past. Despite this people can still be heard discussing memory leakage in Java programs. The name is the same but the cause is now completely different: now, rather than forgetting to delete the object, the programmer has added it to a collection and forgotten to—remove it or provide any mechanism to otherwise cleanup the collection. There are various potential mechanisms provided by Java such as ‘Soft’ and ‘Weak’ references and various collections built upon them which can be used to solve these possibilities, but they tend to be used by a minority of programmers. The net result is that Java programs run out of memory and it is often hard to determine the precise cause. There have been many attempts to provide tools which help diagnose the source of the ‘leakage’. Generally they rely on comparing snapshots of the heap over time. By examining the difference between two snapshots it is often possible to determine which structures 55 e.g., lists or other collections) are growing and this can give a guide to the solution.
From US patent publication no. 2004/0078540A1 there is known a technique for detecting leaks by concentrating on monitoring the sizes of collections. The allocation of a collection is tracked and then subsequently its size is monitored, and collections which are growing are reported. Although the technique can aid in reducing memory leakage, it requires collections to be recognised and so it is not appropriate for automatic leak detection.
From U.S. Pat. No. 6,523,141 there is known a technique for locating memory leakage in non-Java code, typically Operating System kernel code. From a crash dump it attempts to locate pieces of memory which have been allocated but are no longer referenced. By implication these pieces of memory should have been freed and the fact that they have not been freed means that there has been a memory leak. If we can work out where those pieces of memory were allocated, then the leaks can be fixed. The answer is to keep the allocation site information for every allocated object. If one of them is later found to have leaked, it can be determined immediately where it was allocated. However, this technique is not applicable to Java since Java's garbage collector finds and reuses all unreferenced memory.
A need therefore exists for memory leak detection in software such as Java wherein the above mentioned disadvantage(s) may be alleviated.